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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


PPP also defines an extensible Link Control Protocol, which allows 
negotiation of a Quality Protocol for continuous monitoring of the 
viability of the link. 


This document defines a protocol for generating Link-Quality-Reports. 
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Introduction 


In order to establish communications over a point-to-point link, each 
end of the PPP link must first send LCP packets to configure the data 
link during Link Establishment phase. During the Authentication and 
Network-Layer Protocol phases, the link may be tested to determine if 
quality is sufficient for operation. This testing is completely 
optional. 


If an implementation desires that the peer use some specific link 
quality monitoring protocol, then it MUST negotiate the use of that 
protocol using the Quality-Protocol Configuration Option during Link 
Establishment phase. 


The negotiation mechanism is independent in each direction. However, 
if the peer agrees to send Quality-Protocol packets, it MUST 
correctly process such packets on reception, even if it does not 
request such packets or implement a monitoring policy. 


Link Quality Monitoring 


Data communications links are rarely perfect. Packets can be dropped 
or corrupted for various reasons (line noise, equipment failure, 
buffer overruns, etc.). Sometimes, it is desirable to determine 
when, and how often, the link is dropping data. For example, routers 
may want to temporarily allow another route to take precedence. An 
implementation may also have the option of disconnecting and 
switching to an alternate link. The process of determining data loss 
is called "Link Quality Monitoring". 


1. Design Motivation 


There are many different ways to measure link quality, and even more 
ways to react to it. Rather than specifying a single scheme, Link 
Quality Monitoring is divided into a "mechanism" and a "policy". PPP 
fully specifies the "mechanism" for Link Quality Monitoring by 
defining the Link-Quality-Report (LOR) packet and specifying a 
procedure for its use. 


PPP does NOT specify a Link Quality Monitoring "policy" -- how to 
judge link quality or what to do when it is inadequate. That is left 
as an implementation decision, and can be different at each end of 
the link. Implementations are allowed, and even encouraged, to 
experiment with various link quality policies. The Link Quality 
Monitoring mechanism specification ensures that two implementations 
with different policies may communicate and interoperate. 
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To allow flexible policies to be implemented, the PPP Link Quality 
Monitoring mechanism measures data loss in units of packets, octets, 
and Link-Quality-Reports. Each measurement is made separately for 
each half of the link, both inbound and outbound. All measurements 
are communicated to both ends of the link, so that each end of the 
link can implement its own link quality policy for both its outbound 
and inbound links. 


Finally, the Link Quality Monitoring protocol is designed to be 
implementable on many different kinds of systems. Although it may be 
common to implement PPP (and especially Link Quality Monitoring) as a 
single software process, multi-process implementations with hardware 
support are also envisioned. The PPP Link Quality Monitoring 
mechanism provides for careful definition of the Link-Quality-—Report 
packet format, and specifies reference points for all data 
transmission and reception measurements. 


2.2. Counters 


Each Link Quality Monitoring implementation maintains counts of the 
number of packets and octets transmitted and successfully received, 
and periodically transmits this information to its peer in a Link- 
Quality-Report packet. 


These counters are similar to sequence numbers; they are constantly 
increasing to give a "relative" indication of the number of packets 
and octets communicated across the outbound link. By comparing the 
values in successive Link-Quality-Reports, an LOR receiver can 
compute the "delta" number of packets and octets successfully 
communicated across the link. Comparing these absolute numbers then 
gives an indication of a link’s quality. Relative numbers, rather 
than absolute, are transmitted because they greatly simplify link 
synchronization. 


The Link-Quality-Report uses the Interface counters defined by SNMP 
MIB-II [2]. These counters are not initialized to any particular 
value when the LCP enters the Establishment phase. 


In addition, the Link-Quality-Report requires the implementation of 


the following three unsigned, monotonically increasing counters which 
conform to the type and size requirements for SNMP MIB Counters [3]. 
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OutLORs 


OutLORs is a 32-bit counter which increases by one for each 
tranmitted Link-Quality-Report packet. This counter MUST be set 
to zero when the LCP enters the Establishment phase, and MUST NOT 
be reset until the LCP leaves the Termination phase. This counter 
is incremented before it is inserted into the LOR packet. 


InLQRs 


InLORs is a 32-bit counter which increases by one for each 
received Link-Quality-Report packet. This counter MUST be set to 
zero when the LCP enters the Establishment phase, and MUST NOT be 
reset until the LCP leaves the Termination phase. This counter is 
incremented before it is inserted (in an implementation dependent 
fashion) into the LOR packet. 


InGoodOctets 


InGoodOctets is a 32-bit counter which increases by the number of 
octets in each successfully received Data Link Layer packet. 
Unlike the MIB ifInOctets, octets for frames which are counted in 
ifInDiscards and ifInErrors MUST NOT be counted. This counter MAY 
be set to any initial value when the LCP enters the Establishment 
phase, but MUST NOT be reset until the LCP leaves the Termination 
phase. 


2.3. Counting Packets and Octets 


The intent of the counters is to provide an indication of the amount 
of information passing over the link, rather than an actual 
measurement of the total bandwidth used. This specification is 
designed to yield the same count in various circumstances, such as 
when a separate device provides the framing and escaping mechanisms 
invisibly to the implementation, or a synchronous-to-asynchronous 
converter in the link changes between mechanisms. 


All octets which are included in the FCS calculation MUST be counted, 
including the packet header, the information field, and any padding. 
The FCS octets MUST also be counted, and one flag octet per frame 
MUST be counted. All other octets (such as additional flag 
sequences, and escape bits or octets) MUST NOT be counted. 


When inserting the packet and octet counts in the LOR, the counts 
MUST include the expected values for the LOR itself. 
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2.4. 


Processes 


The PPP Link Quality Monitoring mechanism is described using a 
"logical process" model. As shown below, there are five logical 
processes duplicated at each end of the duplex link. 


a ea + +-------+ +----—+ Outbound 
|-->| Mux |-->| Tx | =========> 
Link- +t------ + === 
Manager 
+------- + +----+ Inbound 
|<--| Demux |<--| Rx |<========= 
ata ascot + to- 77+ +----+ 


Link-Manager 


Mux 


Tx 


The Link-Manager process transmits and receives Link-Quality- 
Reports, and implements the desired link quality policy. LOR 
packets are transmitted at a constant rate, which is negotiated by 
the LCP Quality-Protocol Configuration Option. 


The Mux process multiplexes packets from the various protocols 
(e.g., LCP, IP, XNS, etc.) into a single, sequential, and 
prioritized stream of packets. lLink-Quality-—Report packets MUST 
be given the highest possible priority to insure that link quality 
information is communicated in a timely manner. 


The Tx process maintains the MIB counters ifOutUniPackets and 
ifOutOctets, and the internal counter OutLORs, which are used to 
measure the amount of data which is transmitted on the outbound 
link. When Tx processes a Link-Quality-Report packet, it inserts 
the values of these counters into the corresponding PeerOut... 
fields of the packet. The Tx process MUST follow the Mux process 
so that packets are counted in the order transmitted to the link. 


The Rx process maintains the MIB counters ifInUniPackets, 
ifInDiscards, ifInErrors and IfInOctets, and the internal counters 
InLQRs and InGoodOctets, which are used to measure the amount of 
data which is received by the inbound link. When Rx processes a 
Link-Quality-Report packet, it inserts the values of these 
counters into the corresponding SavelIn... fields of the packet (in 
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an implementation dependent manner). 
Demux 


The Demux process demultiplexes packets for the various protocols. 
The Demux process MUST follow the Rx process so that packets are 
counted in the order received from the link. 


2.5. Configuration Option Format 


Description 


Implementations MUST be prepared to receive the Quality-Protocol 
Configuration Option for the Link-Quality-Report. However, 
negotiation is not required. Negotiation is only necessary when 
the implementation wishes to ensure that the peer transmits Link- 
Quality-Reports as opposed to some other Quality-Protocol, or else 
to prevent the peer from maintaining its own timer, or else to 
establish a maximum time between transmissions of Link-Quality- 
Reports. 


A summary of the Quality-Protocol Configuration Option format to 
negotiate the Link-Quality-—Report is shown below. The fields are 
transmitted from left to right. 


0 pi 2 3 
Od, 2-3 445.56 7 287 9-0 L238 E E S P08. 9201 23 4 A E e 9. O 
Potato tototaotata tata tata tate tatatatatotat ai tata tate tate titetitetat 

| Type | Length | Quality-Protocol 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++H++HHH 
| Reporting-Period | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++HHHHH 


Type 


Length 


Quality-Protocol 


c025 (hex) for Link-Quality-Report 
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Reporting-—Period 


The Reporting-Period field is four octets and indicates the 
maximum time in hundredths of seconds between transmission of 


packets. The peer MAY transmit packets at a faster rate than that 
which was negotiated. 


A value of zero indicates that the peer does not need to maintain 
a timer. Instead, the peer generates a LOR immediately upon 
receiving a LOR. A value of zero MUST be Nak’d by the peer with 
an appropriate non-zero value when that peer has sent or will send 
a Configure-Request packet containing the Quality-—Protocol 
Configuration Option for the Link-Quality-Report with a zero 
Reporting-Period. 
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2.6. Packet Format 


Exactly one Link-Quality-Report packet is encapsulated in the 
Information field of PPP Data Link Layer frames where the protocol 
field indicates type hex c025 (Link-Quality-Report). A summary of 
the LOR packet format is shown below. The names of the fields are 
relative to the packet receiver, since it is the receiver who 
requested the packet in the Configuration Option. The fields are 
transmitted from left to right. 


0 1 2 3 
Ob e345 56 PB 980) AY 2 3 -4e SG TE 8 9. OD 2 3? 4a 5, 6 FB 92°0F 
Foto tatatototita to totata ta taotata ta taotatatatotatatatatetatatatatat 
| Magic-Number | 
Foto tatatataotata ta taotata ta taotatatataotatatataitatatatatetatitatatat 
| LastOutLORs | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+tt+HH HHHH 
| LastOutPackets | 
Foto totatataotata to taotata ta tatatatataotatatataitatatatatetatatatatat 
| LastOutOctets | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| PeerInLQRs | 
Foto tatatatatata ta totata ta taotatatataotatatataitatatatatetatatatetat 
| PeerInPackets | 
Foto tatatatotata ta totata ta taotata ta taototatataitaitatatatetatatatatat 
| PeerInDiscards | 
a 
| PeerInErrors | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++t+tt HHHH 
| PeerInOctets | 
Foto titatataotata ta totata ta tetatatataotatatatatatatatatetatatatatet 
| PeerOutLOQRs | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +H 
| PeerOutPackets | 
Fotatata ta tatita ta taotata ta totatatatatatatatatatatatatatatitatatat 
| PeerOutOctets | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 


The following fields are not actually transmitted over the inbound 


link. Rather, they are logically appended (in an implementation 
dependent manner) to the packet by the implementation’s Rx process. 
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+o4-4-4-4-t-t-F-t-t- 4-4-4 -F-t ttt ttt t-te tatatitit-4-4-4-4-4 
| SaveInLOQRs | 
+o4-4-4-4-t-t- ttt 4-4-4 -F-tatatititi toto t ita tatititot-4-4-4-4-4 
| SaveInPackets | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 4-4 titi tatitot-4-4-4-4-4+ 
| SaveInDiscards | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| SaveInErrors | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 
| SaveInOctets | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 4-4 tatatititit-4-4-4-4-4 


Magic-—Number 


The Magic-Number field is four octets and aids in detecting links 
which are in the looped-back condition. Unless modified by a 
Configuration Option, the Magic-Number MUST be transmitted as zero 
and MUST be ignored on reception. If Magic-Numbers have been 
negotiated, incoming LOR packets SHOULD be checked to ensure that 
the local end is not seeing its own Magic-Number and thus a 
looped-back link. See the Magic-Number Configuration Option for 
further explanation. 


LastOutLQRs 


The LastOutLORs field is four octets, and is copied from the most 
recently received PeerOutLORs on transmission. 


LastOutPackets 


The LastOutPackets field is four octets, and is copied from the 
most recently received PeerOutPackets on transmission. 


LastOutOctets 


The LastOutOctets field is four octets, and is copied from the 
most recently received PeerOutOctets on transmission. 


PeerInLQRs 


The PeerInLORs field is four octets, and is copied from the most 
recently received SaveInLORs on transmission. 


Whenever the PeerInLORs field is discovered to be zero, the 


LastOut... fields are indeterminate, and the PeerIn... fields 
contain the initial values for the peer. 
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PeerInPackets 


The PeerInPackets field is four octets, and is copied from the 
most recently received SaveInPackets on transmission. 


PeerInDiscards 


The PeerInDiscards field is four octets, and is copied from the 
most recently received SaveInDiscards on transmission. 


PeerInErrors 


The PeerInErrors field is four octets, and is copied from the most 
recently received SaveInErrors on transmission. 


PeerInOctets 


The PeerInOctets field is four octets, and is copied from the most 
recently received SaveInOctets on transmission. 


PeerOutLORs 


The PeerOutLORs field is four octets, and is copied from OutLORs 
on transmission. This number MUST include this LOR. 


PeerOutPackets 
The PeerOutPackets field is four octets, and is copied from the 
current MIB ifOutUniPackets and ifOutNUniPackets on transmission. 
This number MUST include this LOR. 

PeerOutOctets 
The PeerOutOctets field is four octets, and is copied from the 
current MIB ifOutOctets on transmission. This number MUST include 
this LOR. 

SaveInLQRs 


The SaveInLORs field is four octets, and is copied from InLQRs on 
reception. This number MUST include this LOR. 


SavelInPackets 
The SaveInPackets field is four octets, and is copied from the 


current MIB ifInUniPackets and ifInNUniPackets on reception. This 
number MUST include this LOR. 
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SaveInDiscards 


The SaveInDiscards field is four octets, and is copied from the 
current MIB ifInDiscards on reception. This number MUST include 
this LOR. 


SavelInErrors 
The SaveInErrors field is four octets, and is copied from the 
current MIB ifInErrors on reception. This number MUST include 
this LOR. 

SavelInOctets 
The SaveInOctets field is four octets, and is copied from the 
current InGoodOctets on reception. This number MUST include this 
LOR. 
Note that InGoodOctets is not the same as the MIB ifInOctets 


counter, as InGoodOctets does not include octets for packets which 
are discards or errors. 
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2.7. Transmission of Reports 


When the PPP Link Control Protocol has reached the Opened state, the 
Link Quality Monitoring process MAY commence sending Link-Quality- 
Reports. If a Protocol-Reject is received specifying a LOR packet, 
the LOM process MUST cease sending LORs. 


Usually, the LOR is transmitted when the LOR timer for the link 
expires. If no LOR timer is used, a LOR is generated upon receipt of 
an incoming LOR. The negotiation process ensures that at least one 
side of the link is using a LOR timer. 


In addition, a LOR is generated whenever two successive LORS are 
received which have the same PeerInLOQRs value. This may indicate 
that a LOR has been missed, or that the implementation is sending at 
a significantly slower rate than the peer, or that the peer has 
accelerated LOR generation to better quantify errors on the link. 


Whenever a LOR is sent, the LOR timer MUST be restarted. 
2.8. Calculations 


Each time a Link-Quality-Report packet is received from the inbound 
link, the Link-Manager can compare the associated fields. The fields 
of the previous LOR can be subtracted from the current LOR values to 
obtain an absolute "delta", which allows comparision of the changes 
seen by each end of the link. 


If the received PeerInLORs field is zero, the LastOut... fields are 
indeterminate, and the PeerIn... fields contain the initial values 
for the peer. No calculations using these fields can be performed at 
this time. 


Implementation Note: 
The following counters wrap to zero when their maximum value is 
reached. Care must be taken to ensure that correct "delta" 


calculations are performed at that time. 


The LastOutLORs field may be directly compared with the PeerInLORs 
field to determine how many outbound LORs have been lost. 


The LastOutLORs field may be directly compared with the OutLORs 


counter to determine how many outbound LORs are still in the 
pipeline. 
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The change in PeerInPackets may be compared with the change in 
LastOutPackets to determine the number of lost packets over the 
outgoing link. 


The change in PeerInOctets may be compared with the change in 
LastOutOctets to determine the number of lost octets over the 
outgoing link. 


The change in SaveInPackets may be compared with the change in 
PeerOutPackets to determine the number of lost packets over the 
incoming link. 


The change in SaveInOctets may be compared with the change in 
PeerOutOctets to determine the number of lost octets over the 
incoming link. 


The change in the PeerInDiscards and PeerInErrors fields may be used 
to determine whether packet loss is due to congestion in the peer 
rather than physical link failure. 


2.9. Failure Detection 


When the link is operating well in both directions of the link, the 
LOR is superfluous. The maximum time interval for transmitting LORs 
SHOULD be chosen to minimally interfere with active traffic. 


When there is a measurable loss of data in either direction, if the 
overall throughput is adequate, conditions are not severe enough to 
warrant dropping the link. Sending LORs faster will gain nothing, 
except to measure peaks in the loss rate. The time interval MUST be 
chosen to be long enough to have a good smoothing effect on the data, 
while short enough to ensure fast enough response to complete 
failure. 


When the link is good incoming, but very bad outgoing, incoming LORs 
indicate a high loss on the outgoing side of the link. Sending LORs 
faster won’t help, because they are probably lost on the way to the 
peer. 


When the link is good outgoing, but very bad incoming, incoming LRQs 
will be frequently lost. In this case, LORs SHOULD be sent at a 
faster rate. This primarily relies on the peer to make an informed 
policy decision. The peer will also send LORs in response (due to 
the duplicate PeerInLOQRs field), and some of those LORs may 
successfully arrive. 
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When a LOR does not arrive within the time expected, or the LOR 
received indicates that the links are truly bad, at least one 
additional LOR SHOULD be sent. An algorithmic decision requires at 
least 2 round trip intervals. The loss rate could be transient, due 
to a heavily loaded link, or a lost outgoing LOR. 


2.10. Policy Suggestions 


Link-Quality-Report packets provide a mechanism to determine the link 
quality, but it is up to each implementation to decide when the link 
is usable. It is recommended that this policy implement some amount 
of hysteresis so that the link does not bounce up and down. One 
policy is to use a K out of N algorithm. In such an algorithm, there 
must be K successes out of the last N periods for the link to be 
considered of good quality. 


Procedures for recovery from poor quality links are unspecified and 
may vary from implementation to implementation. A suggested approach 
is to immediately close all other Network-Layer protocols (i.e., 
cause IPCP to transmit a Terminate-Request), but to continue 
transmitting Link-Quality-Reports. Once the link quality again 
reaches an acceptable level, Network-Layer protocols can be 
reconfigured. 
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Security Considerations 
Security issues are not discussed in this memo. 
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